%% Based on a TeXnicCenter-Template by Tino Weinkauf.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% HEADER
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\documentclass[a4paper,12pt]{article}
% Alternative Options:
%	Paper Size: a4paper / a5paper / b5paper / letterpaper / legalpaper / executivepaper
% Duplex: oneside / twoside
% Base Font Size: 10pt / 11pt / 12pt


%% Normal LaTeX or pdfLaTeX? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% ==> The new if-Command "\ifpdf" will be used at some
%% ==> places to ensure the compatibility between
%% ==> LaTeX and pdfLaTeX.
\newif\ifpdf
\ifx\pdfoutput\undefined
	\pdffalse              %%normal LaTeX is executed
\else
	\pdfoutput=1           
	\pdftrue               %%pdfLaTeX is executed
\fi


%% Fonts for pdfLaTeX %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% ==> Only needed, if cm-super-fonts are not installed
\ifpdf
	%\usepackage{ae}       %%Use only just one of these packages:
	%\usepackage{zefonts}  %%depends on your installation.
\else
	%%Normal LaTeX - no special packages for fonts required
\fi


%% Language %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\usepackage[francais]{babel}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}


%% Packages for Graphics & Figures %%%%%%%%%%%%%%%%%%%%%%%%%%
\ifpdf %%Inclusion of graphics via \includegraphics{file}
	\usepackage[pdftex]{graphicx} %%graphics in pdfLaTeX
\else
	\usepackage[dvips]{graphicx} %%graphics and normal LaTeX
\fi
%\usepackage[hang,tight,raggedright]{subfigure} %%Subfigures inside a figure
%\usepackage{pst-all} %%PSTricks - not useable with pdfLaTeX


%% Line Spacing %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\usepackage{setspace}
%\singlespacing        %% 1-spacing (default)
\onehalfspacing       %% 1,5-spacing
%\doublespacing        %% 2-spacing


%% Other Packages %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\usepackage{a4wide} %%Smaller margins = more text per page.
%\usepackage{fancyhdr} %%Fancy headings
%\usepackage{longtable} %%For tables, that exceed one page



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% DOCUMENT
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{document}

\ifpdf
	\DeclareGraphicsExtensions{.pdf,.jpg,.png}
\else
	\DeclareGraphicsExtensions{.eps}
\fi

\pagestyle{empty}

\title{XML Driven Application Development}

\author{Nathan Jones, Richard Wilburn, Aaron Bishell}

\maketitle

\pagestyle{plain}

\abstract

XML-Schema can be used to script the development of many aspects of an application. In this report we demonstrate how XML-Schema can be used to improve the development process of a client-server application. The schema describes the data and communication models used by both client and server. It was found that plain XML-Schema has limitations in scripting the development of an application because it can only describe the data used by the applications, and not the logic for how it should be manipulated.


\section{Introduction}

Distributed applications must have a definition of the services they provide before development begins. The definition models part of the system using a constraint model. It should be possible to use this data constraint model to engineer at least part of the working system.

Some of the questions to be addressed include:

\begin{enumerate}
	\item What is communicated?
	\item How is this communicated?
	\item What technology can we use to generate a GUI from an XSD?
	\item What technology can we use to automate database commands from an XSD?
	\item How much run-time and build-time generation should we use?
\end{enumerate}

Because the boundaries between client and server are clearly defined before any implementation takes place, it is possible to simultaneously develop different client- and server-side applications. For example, a web service might need to have a client available from a web browser as well as available as a desktop application. These two implementations could be developed simultaneously, and even by different vendors if the web service is freely available.

\section{Background}

\subsection{Schema-Oriented Design}

Schema-oriented design is related to the MDA (model driven architecture) which was originally proposed by the OMG (object management group) in 2001. Its intention is not just to drive the software development but to actually integrate the models into the application itself, so the application is driven by the models at either build-time or run-time. As opposed to the MDA which seperates design from architecture, schema-oriented design seperates specific models relevant to the application from the the actual code itself.

Specifically this makes use of a shared constraint model, in our case XML Schema, to represent the data model of the application. 


\subsection{Tools for Schema-Driven Development}

With the rise of XML technology many tools have also been created to aid the development and flexibility of applications. Both Java and .Net have a range of tools which take advantage of XML-Schema to help the application developer.

The Java Architecture for XML Binding (JAXB)\cite{jaxb} can generate Java classes from an XML Schema. It can also serialise instances of the generated classes into XML which is valid against the generating schema.

HyperJAXB extends the JAXB reference implementation to include a Hibernate mapping generator\cite{hyperjaxb}.

All of the Java tools which generate code at build-time require a scripting engine. All of the commonly used Java tools provide support for Ant for scripting.

At the client side Microsoft Infopath was used to generate .NET user interfaces from the XML schema.

Another tool used in the client was the Microsoft XSD Inference tool which exchanges XML schemas into schema instances, and C\# classes.

An alternative product to the XSD Inference tool was Dingo which is also a tool for .NET. Dingo and the XSD Inference tool are similar to JAXB which was used during server development.


\section{Developing the Prototype}

The context we used for this architecture was a book catalogue service which was hosted on the server. Clients could search for books and update a books feedback or rating. The server received such requests and issues responses to the client in the form of search results.

This project and respective tasks for implementing it could be broken into sections and as long as the relationship between these sections was well understood and followed, we would be able to develop the individual components separate from the others (necessary for a group based approach to implementing the prototype). The components of this project are summarised in figure \ref{fig:components}.

\begin{figure}
	\centering
		\includegraphics[width=1.00\textwidth]{images/components.PNG}
	\caption{Components for the sample implementation}
	\label{fig:components}
\end{figure}

Figure \ref{fig:components} illustrates that the application development can be thought of in terms of three kinds of models:

\begin{enumerate}
	\item Data model Represented with the XML schemas (and the database schema), contributes to the GUI, the database, and client-server communication.
	\item Object model Built from the data model and the process model.
	\item Process model Used to influence the client (GUI and communications) and server (communications) to inform them about requests and responses.
\end{enumerate}

Much of the exploratory research determined how the process model is derived from the data model. The fore mentioned architecture is only semi-dynamic (not all of it is tightly coupled with the XML Schema) and therefore assumptions need to be made when defining the process model. These assumptions will guide the user in the GUI, and will tell the server what to expect in a request and what to return in a response.

Shown in figure \ref{fig:architecture} is the initial plan for the client-server interaction. The main point of interest is the mutliple schemas. Multiple schemas have been chosen as an attempt to simplify design by encapsulating different aspects of the communication.

\begin{figure}
	\centering
		\includegraphics[width=1.00\textwidth]{images/architecture.PNG}
	\caption{Overall architecture of the sample implementation.}
	\label{fig:architecture}
\end{figure}


\subsection{Client-Server Communication}

A model of the communication to be expected between client and server must first be developed. This model needs to include descriptions of the entities being communicated about (the data model), the available operations which can be performed on the data, and also any other information which needs to be communicated such as exceptions. This is basically a web services description. 

SOAP provides the ability to describe exactly this type of communication model with Web Services Description Language (WSDL), but we have taken a much more light-weight approach by using only raw XML-Schema for the description of our web services. An XML-Schema can describe the underlying data model used by both client and server, and also describe the structure of the objects which encapsulate a request or response. Tools for creating plain XML-Schema are more accessible than those for developing WSDL documents - XMLSpy only provides the visual WSDL editor with its professional edition\cite{xmlspy}.

The description of our web services was divided into two XML-Schemas. The first schema is for describing the data model (the book catalogue) and is shown in figure \ref{fig:catalogue}. The second schema is used for describing the communication objects and is shown in figure \ref{fig:query}. Seperating the schemas like this is mainly for convenience when using the tools which generate various parts of the application. The communication schema depends on the data model schema and has five possible root elements, depending on the type of communication - query, submit, or response. An instance of the query schema can simply contain a catalogue element, as defined in the catalogue schema.

\begin{figure}
	\centering
		\includegraphics[scale=0.50]{images/catalogue.PNG}
	\caption{Diagram of the schema used to describe the book catalogue data model. Generated by XMLSpy.}
	\label{fig:catalogue}
\end{figure}

\begin{figure}
	\centering
		\includegraphics[scale=0.50]{images/query.PNG}
	\caption{Diagram of the schema used to describe the client-server communication data. Generated by XMLSpy.}
	\label{fig:query}
\end{figure}

There are a number of restrictions not explicit in the schema which should be honoured by any client or server of the web service: 

\begin{itemize}
	\item any data sent between client and server will be a valid instance of the communication schema.
	\item a client request will contain as a root element one of a search query, a book submission, or a feedback submission.
	\item a server response will contain as a root element one of a response, or a catalogue.
\end{itemize}

Because we have not used SOAP to implement the client-server communication it is reasonable to assume that it must be REST-ful. On the contrary, our communication model is much more SOAP-like than it is REST-ful. It encapsulates client requests and server responses with communication objects, it embeds the serialised objects as XML inside an HTTP post request or response, and it uses a single URL for submission of all client requests. The communication paradigm we have used can be summed up as "generic XML-over-HTTP".


\subsection{Server}

Schema-driven development is well supported in Java. Once the necessary tools are understood, developing the server is almost trivial. Development of the web application can be divided into two reasonably simple tasks:

\begin{enumerate}
	\item Building an Ant script.
	\item Creating a Servlet.
\end{enumerate}

The main responsibility of the Ant script is to generate a set of classes which form an API for manipulating the data model described by the XML-Schema. For this purpose JAXB is used. JAXB can be used to serialise (marshal) any Java objects which instantiate a class which has also been generated using JAXB. The serialised objects will be valid instances of the schema that the classes were generated from. Objects can be de-serialised (unmarshalled) in the same manor. 

\begin{figure}
	\centering
		\includegraphics[scale=0.50]{images/serverArchitectureBuildtime.PNG}
	\caption{The build-time process for the web application.}
	\label{fig:serverArchitectureBuildtime}
\end{figure}

A secondary task of the Ant script is to generate the Hibernate mapping files for the necessary generated classes. Not all of the classes need to be mapped to the relational database and having the data objects and the communication objects described in seperate Schemas helped to make this task easier. The build-time process is shown in figure \ref{fig:serverArchitectureBuildtime}.

We expect an instance of the schema to be sent in the body of an HTTP post request. From a Servlet we can extract this XML content and use JAXB to unmarshal it into a Java object. The object can be inspected with \texttt{instanceof} and then processed accordingly.

If the request contained a submission then the supplied book or feedback object will be inserted into the database using a Hibernate query. The response object will simply contain a success message or a failure message if a problem was encountered. If the request contained a search query then the search criteria will be connected with logical disjunction and submitted as a Hibernate query. The result of the query - a collection of books - will be used as the response object. The response object will be marshalled onto the response stream of the servlet's doPost method. Figure \ref{fig:serverArchitectureRuntime} shows the run-time behaviour of the web application.

\begin{figure}
	\centering
		\includegraphics[scale=0.50]{images/serverArchitectureRuntime.PNG}
	\caption{The run-time behaviour of the web-application.}
	\label{fig:serverArchitectureRuntime}
\end{figure}


\subsection{Client}

The client was made in C\# on the .NET 2.0 framework. We chose this language because it is one of the major players in the mainstream computer languages for enterprise application development. This is important because it is an opportunity to observe community support for schema-driven development in the mainstream.

The goal of the client was not only to successfully instantiate the schema and communicate with the server but to also provide as much flexibility for change in the schema. We feel this is important as it is good software engineering practice to allow for as much change in data and their respective relationships as possible. This section looks at what was hard coded, what was done at compile time, and what was implemented at runtime. Figure \ref{fig:clientArchitecture} shows the architecture of the implemented client. Unfortunately we found that the schema was not expressive enough to clear up ambiguities of how to represent the data. While the schema can be suggestive of layout, if it changes dramatically the representation of that data may no longer apply.

\begin{figure}
	\centering
		\includegraphics[scale=0.50]{images/clientArchitecture.PNG}
	\caption{The basic architecture of the client design.}
	\label{fig:clientArchitecture}
\end{figure}


\subsubsection{Runtime}

The user interface contains a GUI plug-in that loads xml InfoPath generated forms at runtime. This means that if the schema changes the User interface can be regenerated through Microsoft InfoPath (which comes with MS Office) and re run the application; regenerating the form. The form is valid at all times to the schema, and is created from the schema in InfoPath. While it was possible to create this aspect of the user interface at runtime, other aspects were ambiguous in representation and had to be hard coded.  The benefits of using InfoPath is that it generates the form components of the GUI, while still allowing for you to customize its look and feel as long as you keep it valid to the schema.


\subsubsection{Compile time}

We used a tool called the "XSD inference tool" by Microsoft which comes with Visual studio .NET. This tool was integrated into an Nant script (an xml build script for .NET) which generated the source code from the entity schema. This is an argument as to why we needed to split the schemas into the entity and the communication files. The source code generated allowed us to deserialize xml instances of the schema into client-side model objects.


\subsubsection{Hard Coded}

The schema allows for the user to submit a book, query a book and add feedback. This meant that the schema allows for many forms, each of the form controls was hard coded. A tab control to go between these forms was also added. Submit buttons were also hard coded.


\subsection{Run time generation}

The creation of a set of XML driven applications is difficult from a design point of view because it is relatively unexplored and it is not clear from the beginning where to draw the line between the dynamic style of run time (or build time) generation, and what to hard code into the source of an application.

An example was the server performing a search on the database. If the logic to do this is derived from the constraint model (in our case XML Schema) then the server must be able to examine the XSD and infer an SQL query from it. This becomes even more complicated with nested elements.

After deliberation it was decided that it was not feasible, given the time, to make everything completely dynamic and all logic to be derived from a single constraint model. The XSD would be used to provide the logic of some pieces of the application but some logic would be hard coded. Although not as clean, it would require minimal work to update code if modifications were made to the XSD, and simplify the overall project considerably.

The pieces of the application logic which are generated by the XSD are: 

\begin{itemize}
	\item The user interface.
	\item The database schema (via Hibernate).
	\item Database commands (via Hibernate).
	\item The data communicated (instances of parts of the XSD would be sent and received).
\end{itemize}

The pieces of the application logic which were hard coded are:

\begin{itemize}
	\item The extraction of information from an instance received (at the server) and the manipulation of this to form an SQL query.
	\item Some of the GUI code to extract information and insert it into an XSD instance.
\end{itemize}

Once we had decided how much run time impacted the XSD would have, we moved on to other issues.


\section{Discussion and Future Work}

There are many aspects of the schema-driven development process which can be improved on or modified to be more flexible. We will discuss some of these here. A full record of our collective discussions are on our blog\footnote{http://xmldad.blogspot.com/}.

One area worth investigating is that the XML Schema does not just represent the data model (and the communication model) but also the application model. This would define things like the behaviour of the application, its organisation and structure. 

The main advantage of XML based application development is the separation of the data model from the rest of the system, and the fact that most of the system derives from the data model.

Managing old data when the schema (and hence the database) changes is a big issue. Conversion of this architecture to another type of problem while retaining the database information can be achieved easily with XSL. Two things need to be changed: the data model (XML Schema) and the database structure. An XSL document could be written as a single "recipe" which can translate the original XML Schema and an instance of another XSD (which represents the database) and its content into a new format.

A proof of concept client was partially implemented which explored the possibility of developing the client in AJAX. This made use of the XML instances being sent from the server to the client and used an XSL document to transform these into HTML. Using JavaScript to build and send the XSD instance to the server is not a trivial task.

More research would be useful when looking into defining all application logic within the constraint model. To keep complexity to a manageable level some of this logic was hard-coded into the application, however it is theoretically possible to define all logic in an XML Schema document and the entire application to be dependent on it. This would allow extremely simple maintenance without the need for redeployment of the application and could be developed by non-experts. RuleML is a possible contender for this\cite{ruleml}.


\section{Conclusion}
The main principle behind this project was to develop an XML driven application that had two parts, a client and a server.

Not all of the application logic that could be expressed in an XML document was put there so that the complexity of having a completely dynamic application was reduced. However this meant that some of the application logic must be expressed in the code itself, yet this was minimal and only required small changes when the XML Schema changed.

The independent development of a server and multiple clients illustrates the example of such a development method. Interoperability was inherently available and performing maintenance updates to the data model was easy since this was centralised.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% BIBLIOGRAPHY AND OTHER LISTS
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\bibliographystyle{unsrt}
\bibliography{literature}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% APPENDICES
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\end{document}